Typical enterprise resource planning (ERP) systems are very complex with respect to user-specific settings and customizing. A posting engine within ERP is typically also complex. Implementation of new functions or new settings in such environment may be lengthy and costly, especially when a magnitude of a change demands checking of the processes on customer side due to a concern that important processes might get broken.
An existing approach to such changes is to make sure everything will go well after introduction of new functionality. This is typically accomplished by taking financial accounting (FI) documents and posting and processing them twice: once in the current ERP system with the current customizing parameters which are known to be working fine; and the other time through a posting engine that runs in parallel and in the background to the active ERP system and that runs with new customizing. This background testing allows the user or developer to see if processes that have been defined in the particular customer's system with the new customizing settings run into problems or not and to adjust the background system accordingly until it works satisfactorily.
An expectation is that processes in manufacturing, sales, human resources (HR) will stay as they are. It is possible then to take FI documents that result from these processes and run them through an accounting system that has been upgraded with new settings to check if the documents can be posted or not. The main disadvantage of this approach, especially for larger users, is that it takes a long time to run all the documents posted in a given time period, typically in the most recent fiscal year. Such testing can be running for a week or longer due primarily to a large number of documents, reaching upward of one hundred million documents for large enterprises.
The current solution to the underlying problem is running the project in phases. The longest phase, usually spanning several months, is where the new customizing is applied in simulation mode. This approach allows to identify and adapt processes that are not compatible with the changed customizing, prior to Go Live, but it has many disadvantages. Disadvantages of the current process include long implementation times, error messages coming from the simulation jeopardizing important processes in the logistics, this simulation phase running for the whole year in order to identify all incompatible processes so that it would encompass month end, quarter end, and year end closings. This is not acceptable for customers, and some of them may be forced to conduct incomplete simulations prior to Go Live and retain some residual risk.